1. Field of the Invention
The present invention relates to a method by which a cable modem (“CM”) reports a downstream packet resequencing status to a cable modem termination system (“CMTS”), and more particularly, to a method of effectively reporting detailed information on a packet resequencing status by further defining a packet resequencing-related event and event-related information in a message reporting the packet resequencing status.
The present invention has been produced from the work supported by the IT R&D program of MIC (Ministry of Information and Communication)/IITA (Institute for Information Technology Advancement) [2006-S-019-01, The Development of Digital Cable Transmission and Receive System for 1 Gbps Downstream] in Korea.
2. Discussion of Related Art
In general, a cable modem network attracts attention together with an integrated services digital network (ISDN), a multi digital subscriber line (xDSL), and the like in the field of remote connections. The cable modem network provides a variety of services, such as working from home, video conferencing, web surfing and the like, to subscribers at a high data rate on the order of Mbps in connection with the Internet or an Intranet.
A cable modem network is widely used in the U.S. and may be based upon a cable television (CATV) network for data communications. The cable modem network is similar to the CATV network in that it uses a coaxial cable. However, in the CATV network, an external coaxial cable is connected to a set top box, which is then connected with a television (TV), and in the cable modem network, a cable modem is used to connect a coaxial cable with a personal computer (PC). In this case, one or more PCs may be connected to the cable modem.
Referring to FIG. 1, a cable network may include a cable modem (CM) 120 for allowing a user to transmit and receive data, and a cable modem termination system (CMTS) 110 connected to a wide area network for transmitting and receiving data to and from the user. The CMTS 110 is located at a headend and receives data from the CM 120 at home (upstream), and transmits data to the CM 120 (downstream).
The transmission of data packets from the CMTS 110 to the CM 120 may be made by a plurality of downstream channels (DC) rather than one channel. The CM 120 may resequence, in an original order, the packets received over the different channels.
FIG. 2 illustrates a cable modem network in which data transmission and reception is made over a plurality of downstream channels.
Referring to FIG. 2, the CMTS 210 receives packets from a network-side interface (NSI) 240. In the CMTS 210, a classifier 211 classifies the received packets into common packets 215 and resequenced packets 216.
The common packets 215 are directly delivered to a scheduler 213 of the CMTS 210 and then to the CM 220 via one downstream channel 214.
On the other hand, the resequenced packets 216 are first delivered to a sequencer/distributor 212 before being provided to the scheduler. The sequencer sequentially allocates a sequence number to the respective resequenced packets 216, and the distributor distributes the packets to the respective schedulers 213 according to a predetermined rule.
Each channel scheduler 213 of the CMTS 210 transmits the received packet over the downstream channel 214 according to a scheduler algorithm.
The CM 220 processes the packets received over the plurality of downstream channels 214 and transmits the packets to customer premise equipment (CPE).
In this way, the CM 220 receives the common packets from the single channel and the resequenced packets from the plurality of channels. Since the resequenced packets are distributed by the CMTS 210 to the plurality of channels, the received packets at the CM 220 may differ in sequence from the packets input from the network-side interface 240 to the CMTS 210 depending on settings of the schedulers and the downstream channels. In order to transmit the packets to the customer premise equipment in the same sequence input from the network-side interface 240 to the CMTS 210, the CM 220 may perform a packet resequencing process using information received from the CMTS 210 and information included in the packets.
In an initialization process, the CMTS 210 transmits a downstream service ID (“DSID”) to the CM 220, so that the packet resequencing process is performed. The CMTS 210 then includes the DSID together with a packet sequence number (“PSN”) for resequencing in the resequenced packets and transmits the resultant resequenced packets to the CM 200. The CM 220 may perform the packet resequencing process based on such information.
FIG. 3 illustrates a format of the resequenced packet transmitted from the CMTS to the CM.
Referring to FIG. 3, the resequenced packet includes a MAC header 310 and MAC data 320.
The MAC header includes a frame control (FC) field 311 indicating a type of a frame and the presence of an extended header (EHDR), a MAC parameter field (MAC_PARM) 312 indicating a length of the EHDR, a length field (LEN) 313 indicating a total length of the frame, a header check sequence (HCS) field 314 for error check of the MAC header 310, and the EHDR 315 having packet resequencing information and output priority information. The EHDR 315 includes a 4-bit EHDR type field EH_Type, a 4-bit length field EH_LEN, a 3-bit traffic priority field, a 1-bit sequence change counter (“SCC”) field, a 20-bit DSID field, and a 16-bit PSN field.
FIGS. 4a and 4b illustrate a format of a MAC domain description (MDD) message transmitted from the CMTS to the CM, and a type/length/value (TLV) format, respectively. The MDD message is periodically transmitted from the CMTS to the CM over each downstream channel, and mainly used by the CM in an initialization process for transmission between the CMTS and the CM.
Referring to FIG. 4a, the MDD message, which is transmitted from the CMTS to the CM over a primary downstream channel, includes a MAC management header 410, fixed fields 420, and TLV encoding information 430 containing MAC domain information.
FIG. 4b illustrates a TLV format related to the control of transmission of a CM-STATUS message in the TLV encoding information 430 for reporting a resequenced packet status from the CM to the CMTS. Among sub TLVs of a downstream active channel list TLV 440 represented by Type=1, a CM-STATUS event enable bitmask TLV 442 of Type=1.5 (indicating that the CM-STATUS event enable bitmask TLV 442 is a sub TLV of Type=1 and has a type of 5) and a CM-STATUS event control TLV 460 represented by Type=11 describe information for controlling the transmission of the CM-STATUS message.
The CM-STATUS event enable bitmask TLV 442 consists of a 2-byte bitmask. For example, the DOCSIS 3.0 standard defines a fourth bit as a sequence-out-of-range event. The sequence-out-of-range event refers to an event occurring when resequenced packets cannot be stored in a receive buffer due to the limited capacity of the receive buffer.
Where the fourth bit is set to 1, the CM is required to transmit the CM-STATUS message when there is a sequence-out-of-range packet in the resequenced packets received over a downstream channel with a downstream channel ID (“DCID”) indicated by the channel ID TLV 441a. If the fourth bit is 0, the CM does not transmit the CM-STATUS message even if there is the sequence-out-of-range packet.
The CM-STATUS event control TLV 460 includes sub TLVs, such as an event type code TLV 461 of type=11.1, a maximum event hold-off timer TLV 462 of type=11.2, and a maximum number of reports-per-event TLV 463 of type=11.3.
In an exemplary embodiment, the DOCSIS 3.0 standard defines that the event type code value of the sequence-out-of-range event is 3. When the event type code TLV 461 value in the MDD message is 3 and a sequence-out-of-range event occurs, the CM is required to perform CM-STATUS message transmission according to a process shown in FIG. 7 by using the maximum event hold-off timer TLV 462 value and the maximum number of reports-per-event TLV 463 value.
FIGS. 5a and 5b illustrate a format of a multipart registration response (REG-RSP-MP) message transmitted from the CMTS to the CM, and a TLV format, respectively. The REG-RSP-MP message is a message that the CMTS transmits to the CM in response to a registration request message (REG-REQ-MP) from the CM. The REG-RSP-MP message is used for registration of information required for the transmission between the CMTS and the CM.
Referring to FIG. 5a, the REG-RSP-MP message includes a MAC management header 505, fixed fields 510, and TLV encoding information 515 containing registration information.
FIG. 5b illustrates a format of a DSID encoding TLV in TLV information 515 forming the REG-RSP-MP message. The DSID encoding TLV 520 represented by Type=50 includes: sub TLVs, such as a DSID TLV 525 of type=50.1 indicating a DSID value; a DSID action TLV 530 of type=50.2 indicating addition, deletion or change of the DSID indicated in the DSID TLV 525; and a downstream resequencing encoding TLV 535 of type=50.3 describing whether resequencing is required and additive parameter information required for resequencing.
The downstream resequencing encoding TLV 535 includes sub TLVs. That is, the downstream resequencing encoding TLV 535 includes a resequencing DSID indication TLV 540 of type=50.3.1 indicating whether resequencing is required. In the case where resequencing is required, the downstream resequencing encoding TLV 535 further includes, as parameter information: a resequencing channel list TLV 545 indicating channels over which downstream packets with the DSID TLV 525 value can be transferred; a resequencing wait time TLV 550 of type=50.3.3; a resequencing warning threshold TLV 555 of type=50.3.4; and a CM-STATUS maximum event hold-off timer TLV 560 of type=50.3.5 for sequence-out-of-range events.
The maximum event hold-off timer TLV 462 of the MDD message is replaced with the CM-STATUS maximum event hold-off timer TLV 560.
FIGS. 6a and 6b illustrate a format of a CM control request (CM-CTRL-REQ) message transmitted from a CMTS to a CM in order to instruct to perform a specific activity and a TLV format, respectively.
Referring to FIG. 6a, the CM-CTRL-REQ message includes a MAC management message header 610, a fixed transaction ID field 620, and a TLV encoding information field 630.
FIG. 6b illustrates a format of a downstream status event enable bitmask override TLV related to transmission of the CM-STATUS message in TLV encoding information 630 of the CM-CTRL-REQ message. The downstream status event enable bitmask override TLV 640 represented by Type=5 includes sub TLVs, such as a DCID TLV 650 of type=5.1, and a downstream status event enable bitmask TLV 660 of type=5.2. The CM-STATUS event enable bitmask TLV 442 may be replaced with the downstream status event enable bitmask TLV 660.
In response to receipt of the CM-CTRL-REQ message, the CM is required to respond to the CMTS with a CM-CTRL-RSP message, which has the same format as the CM-CTRL-REQ message format as shown in FIG. 6a. 
FIG. 7 illustrates a CM-STATUS event type state machine running on the CM. The CM-STATUS event type state machine is a kind of finite state machine (FSM) for determining, based on event-based state transition of the CM, whether the CM transmits a CM-STATUS message including resequenced packet status information.
Referring to FIG. 7, the CM operates the CM-STATUS event type state machine consisting of an IDLE 705 state and a SENDING 725 state for respective events allowing for transmission of the CM-STATUS message via an MDD message or a CM-CTRL-REQ message.
In the IDLE state 705, the CM has the transaction ID (TID) value of zero. When a state transitions from the IDLE state to an “on” state due to occurrence of an event of a specific type (710), the CM sets a ReportsLeft variable to a maximum number of reports defined for the event and a FirstReport control variable to True (715). The CM then selects any one value between 0 and the maximum hold-off value defined for the event and uses it as an initial reporting hold-off timer (720). The CM then transitions to a SENDING state and is kept in the SENDING state while the defined timer is operating (725).
Upon expiration of the hold-off timer in the SENDING state 725 (730), the CM determines whether the event type is kept in the “on” state (735). If the event is changed to an “off” state, the CM transitions to the IDLE state (705) instead of transmitting the CM-STATUS message.
If the event is kept in the “on” state, the CM determines whether a transmission of the CM-STATUS message is the first time (FirstReport=True) (740). If the transmission is the first time, the CM sets the FirstReport control variable to False and increments the TID value by one. The TID value can increase to 255 and then is reset to one (wraparound). If the FirstReport control variable value is False, the CM maintains the TID value unchanged.
The CM transmits the CM-STATUS message (745). The CM then determines whether the ReportsLeft variable value is zero (750). The zero means that the CM should transmit the CM-STATUS message unlimitedly until the event becomes “off”. If the ReportsLeft value is not zero, the CM decrements the ReportsLeft value by one.
When the ReportsLeft variable value decrements from one to zero, the CM transitions to the IDLE state (705) in step 755. When the ReportsLeft variable value does not decrement from one to zero, the CM sets the hold-off timer to the maximum hold-off value (760).
Where the event of the relevant type is released and then regenerated prior to the expiration of the hold-off timer in the SENDING state 725 in step 765, the CM sets the ReportsLeft variable to a maximum reports value defined for the event again and sets the FirstReport control variable to True (770). Step 770 is the same as step 715, except that the SENDING state is maintained directly without step 720.
If the hold-off timer value for the event type is changed by the MDD message prior to the expiration of the hold-off timer in the SENDING state 725 in step 775, the CM proceeds to step 720.
If the transmission of the CM-STATUS message for the event type generation by the MDD message or CM-CTRL-REQ message is prohibited prior to the expiration of the hold-off timer in the SENDING state 725 in step 780, the CM transitions to the IDLE state (705) instead of transmitting the CM-STATUS message.
FIGS. 8a and 8b illustrate a format of a CM-STATUS message transmitted from the CM to the CMTS, and a TLV format, respectively. Here, the CM-STATUS message is a message that the CM transmits to report a resequencing status to the CMTS when a resequencing-related event occurs at the CM.
Referring to FIG. 8a, the CM-STATUS message includes a MAC management message header 810, a fixed transaction ID field 820, and a TLV encoding information field 830.
FIG. 8b illustrates a TLV format of event information causing transmission of the CM-STATUS message in the TLV encoding information 830 of the CM-STATUS message. The status event TLV 840 represented by Type=1 includes sub TLVs, such as an event type code TLV 845 of type=1.1, an event description TLV 850 of type=1.2 describing details of an event, a transaction ID TLV 855 of type=1.3, a downstream channel ID TLV 860 of type=1.4, an upstream channel ID TLV 865 of type=1.5, and a DSID TLV 870 of type=1.6.
In an exemplary embodiment, when a sequence-out-of-range event occurs at the CM and reporting a status of the sequence-out-of-range event via the MDD message or the CM-CTRL-REQ message is allowed, the CM generates the CM-STATUS message to the CMTS, which includes the event type code TLV 845 value set to 3, the transaction ID TLV 855 value set to a proper value, and the DSID TLV 870 value set to a DSID value to which a packet with an event belongs.
In the conventional cable network using the packets and messages of the format as described above, via the CM-STATUS message the CM notified the CMTS of only a sequence-out-of-range event among several events occurring upon receipt of the resequenced packets from the CMTS. In this case, only DSID information of a packet causing the event is notified via the CM-STATUS message. This allows the CMTS to only delete the packet causing the event by use of the information.
Moreover, the CM-STATUS message is not transmitted immediately after the event occurs. That is, the CM-STATUS message is not transmitted until the band is allocated in response to a queue-depth based resource request (“QD-REQ”) message competitively transmitted for transmission of the CM-STATUS message generated at the time of expiration of the hold-off timer driven by the CM.
According to the reporting scheme used in the conventional cable network, the CM cannot rapidly report accurate information on various situations occurring upon the receipt of the resequenced packets to the CMTS. Furthermore, since the CMTS can receive the resequencing status information if, and only if, an event is generated from the CM, it cannot cope with problematic situations flexibly. In particular, in a CM comprising a receive buffer having limited capacity, a packet loss may be frequently caused by receive buffer overflow.